Skip to main content

Tech Lead Role Overview

As a tech lead, you are responsible for guiding your subteam both technically and organizationally. Your goal is to ensure high code quality, consistent progress, and team alignment with the overall architecture and product direction. This role requires proactive communication, thoughtful code review, and regular check-ins with your team.

Time Commitment: 10–15 hours of work per week.

Core Responsibilities​

  • Approve and review code submissions (PRs) from your team members.
  • Align your team on the big picture: architecture goals, API structure, deadlines, and overall feature scope.
  • Coordinate closely with the core team leads, send any approved code to Abhi/Aryan/Shiven for final review and integration into main branches.

You are permitted to:​

  • Install new packages (npm dependencies) when justified
  • Make schema changes in Prisma, including model modifications and migrations
  • Lead PR reviews, guide architectural decisions, and refactor code where needed
tip

Your work directly influences code quality and developer velocity. Treat the codebase as a shared, long-term asset: scalable, readable, and easy to maintain.

Pull Request (PR) Review Guidelines​

Every PR is an opportunity to improve our codebase. As a tech lead, your review should ensure that all changes follow architectural best practices, prioritize reusability, and minimize technical debt. Pay special attention to the frontend/backend interface, database safety, and clarity of logic.

warning

Approving improper code can cause many headaches eventually.

1. Architectural Conventions​

  • Follow controller → service → route separation
  • Routes should only define the HTTP method and endpoint
  • Controllers should handle request validation, error catching, and call services
  • Services contain all reusable business logic and database access (via Prisma)
  • Keep frontend logic in React components focused
  • Avoid mixing stateful logic and rendering logic, split into hooks/components when necessary
  • Abstract API calls into hooks folders in the frontend

2. Type Safety & Validation​

  • Use JSDoc or inline comments to document all function parameters and return values clearly
  • Add input validation at the controller level using libraries like zod or yup.
  • Ensure Prisma schema changes are accompanied by:
    • Corresponding migrations
    • Model comments explaining why certain changes are needed
    • Updated types/interfaces
    • Additionally go though the code base to ensure nothing else breaks

3. Database & Prisma-Specific Checks​

Ensure queries are:

  • Efficient

  • Safe

  • Confirm all schema changes are intentional and justified

  • Any raw SQL usage must be reviewed carefully for injection vulnerabilities

4. React Frontend Guidelines​

Ensure component logic is:

  • Modular – hooks for logic, components for view
  • Reusable – no excessive prop drilling or copy-paste

Look for:

  • Proper loading/error states
  • Accessible HTML and ARIA labels
  • API calls using centralized hooks
  • Follow established patterns for state management (e.g Context)

5. Naming & Folder Conventions​

  • Routes, services, and controllers should be singular, descriptive, and match the resource
  • Frontend files should follow PascalCase for components and camelCase for hooks/utilities
  • Avoid generic naming without clear function groupings

6. Comments & Clarity​

Complex or non-obvious logic should be commented

Each function should describe:

  • What it does
  • What inputs it expects
  • What it returns

PR description must include:

  • Summary of what changed
  • Screenshots (for frontend UI)
  • Links to related issues, if applicable

7. Unit Testing​

  • Properly uses Jest to test all services
  • Properly uses react-testing-library to test components
  • Ensure there are tests for null and edge cases

8. Final Checklist Before Approving​

  • All routes/controllers/services follow architectural conventions
  • All inputs are validated and errors handled gracefully
  • Prisma interactions are safe and efficient
  • React components are modular, reusable, and handle loading/error states
  • Naming and file structure follow our team conventions
  • The PR is well-documented and scoped (no unrelated changes)
  • Proper unit tests written

AI Usage Guidelines​

We support the use of AI tools (like ChatGPT, Claude, GitHub Copilot, and others) to accelerate development, but any AI-generated code must be critically reviewed, cleaned up, and properly tested before being merged.

What's Allowed​

  • Using AI to scaffold boilerplate code, utilities, or common patterns
  • Generating basic unit tests or test case scaffolds
  • Refactoring or rewriting repetitive code for clarity

Requirements for AI-Generated Code​

Must be manually reviewed and cleaned up

  • AI-generated code often includes unnecessary code or poor abstractions
  • Watch for magic numbers, redundant checks, or hard coded assumptions
  • If it feels bloated, it definitely is, please refactor

Should be tested just like human-written code

  • Run the code yourself, and confirm it behaves as expected
  • Ensure full coverage of edge cases, especially when using AI to generate unit tests
  • Do not rely solely on AI-generated test cases, use them as a starting point only

Should be abstracted and aligned with our patterns

  • Move logic into services, hooks, or shared utilities as needed
  • All AI-generated code must follow the same controller → service → route structure
  • AI is good at scaffolding, but it's your job to integrate it cleanly

What to Avoid​

danger
  • Copy-pasting large blocks of code without understanding or editing it
  • Using AI-generated code that skips validations or hardcodes assumptions
  • Allowing AI-written logic to live in routes/controllers directly without abstraction

Weekly Meetings (1 hr)​

Make sure to meet with your team at least once a week. Use this time to discuss everyone's work, ensure each person has written at least some code, and help unblock any stuck teammates. The goal is to get at least 1 PR per person, every week, and keep the pace consistent.

Make sure everyone understands the big picture and how their work contributes to it, review architecture decisions, upcoming deadlines, or changes to schema/services.

Documentation

Document everything: take meeting notes, track decisions, and create a shared document where everyone can record their weekly progress, PR links, and major changes. This helps with transparency, accountability, and team alignment.